home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1430.txt < prev    next >
Text File  |  1994-08-01  |  48KB  |  1,123 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                S. Hardcastle-Kille
  8. Request for Comments: 1430                              ISODE-Consortium
  9.                                                                E. Huizer
  10.                                                               SURFnet bv
  11.                                                                  V. Cerf
  12.                            Corporation for National Research Initiatives
  13.                                                                 R. Hobby
  14.                                          University of California, Davis
  15.                                                                  S. Kent
  16.                                                 Bolt, Beranek and Newman
  17.                                                            February 1993
  18.  
  19.  
  20.                    A Strategic Plan for Deploying an
  21.                     Internet X.500 Directory Service
  22.  
  23. Status of this Memo
  24.  
  25.    This memo provides information for the Internet community.  It does
  26.    not specify an Internet standard.  Distribution of this memo is
  27.    unlimited.
  28.  
  29. Abstract
  30.  
  31.    There are a number of reasons why a new Internet Directory Service is
  32.    required.  This document describes an overall strategy for deploying
  33.    a Directory Service on the Internet, based on the OSI X.500 Directory
  34.    Service.  It then describes in more detail the initial steps which
  35.    need to be taken in order to achieve these goals, and how work
  36.    already undertaken by Internet Engineering Task Force Working Groups
  37.    (IETF WGs) is working towards these goals.
  38.  
  39. Table of Contents
  40.  
  41.    1.    REQUIREMENTS                                                  2
  42.    2.    SUMMARY OF SOLUTION                                           3
  43.    3.    INFORMATION FRAMEWORK                                         3
  44.    3.1   The Technical Model                                           3
  45.    3.2   Extending the Technical Model                                 4
  46.    3.3   The Operational Model                                         5
  47.    4.    NAME ASSIGNMENT                                               5
  48.    5.    DIRECTORY INFRASTRUCTURE                                      6
  49.    5.1   Short Term Requirements                                       7
  50.    5.2   Medium Term Requirements                                      9
  51.    5.3   Long Term Requirements                                        9
  52.    6.    DATAMANAGEMENT                                                9
  53.    6.1   Legal Issues                                                 10
  54.    7.    TECHNICAL ISSUES                                             10
  55.  
  56.  
  57.  
  58. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 1]
  59.  
  60. RFC 1430                     X.500 Strategy                February 1993
  61.  
  62.  
  63.    7.1   Schema                                                       11
  64.    7.2   Use on the Internet                                          11
  65.    7.3   Replication of Knowledge and Data                            12
  66.    7.4   Presentation of Directory Names                              13
  67.    7.5   DSA Naming and MD Structure                                  13
  68.    8.    SECURITY                                                     13
  69.    8.1   Directory Provision of Authentication                        14
  70.    8.2   Directory Security                                           15
  71.    9.    RELATION TO DNS                                              16
  72.    10.   EXTERNAL CONNECTIONS                                         16
  73.    11.   REFERENCES                                                   17
  74.    12.   Security Considerations                                      19
  75.    13.   Authors' Addresses                                           20
  76.  
  77. 1.  REQUIREMENTS
  78.  
  79.    There is substantial interest in establishing a new Directory Service
  80.    on the Internet. In the short term, there is pressure to establish
  81.    two new services:
  82.  
  83.    -  White Pages lookup of users;
  84.  
  85.    -  Support for X.509 Authentication for a range of applications in
  86.       particular for Privacy Enhanced mail [Lin89].
  87.  
  88.    In the medium term, there are likely to be many requirements for
  89.    Directory Services, including:
  90.  
  91.    - General resource lookup, for information ranging from committee
  92.      structures to bibliographic data;
  93.  
  94.    - Support of management of the Internet infrastructure, and
  95.      integration of configuration information into the higher level
  96.      directory;
  97.  
  98.    - Support of applications on the Internet. For example:
  99.  
  100.       o  Electronic distribution lists;
  101.       o  Capability information on advanced user agents;
  102.       o  Location of files and archive services.
  103.  
  104.    - Support for Mail Handling Systems; Be they RFC-822 based or X.400
  105.      based (IETF MHS-DS WG), e.g.,:
  106.  
  107.       o  Support for routing;
  108.       o  Info on User agent capabilities; essential for a usage of
  109.          Multimedia mail like MIME (Multipurpose Internet Mail
  110.          Extensions).
  111.  
  112.  
  113.  
  114. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 2]
  115.  
  116. RFC 1430                     X.500 Strategy                February 1993
  117.  
  118.  
  119.    For the longer term, more sophisticated usages of X.500 are possible
  120.    extending it into a useful and fast yellow pages service.
  121.  
  122. 2. SUMMARY OF SOLUTION
  123.  
  124.    In principle, the current Internet Domain Name System (DNS) could be
  125.    used for many of these functions, with appropriate extensions.
  126.    However, it is suggested that a higher level of directory service is
  127.    needed. It is proposed to establish an Internet Directory Service
  128.    based on X.500.  This provides appropriate functionality for the
  129.    services envisaged and gives flexibility for future extension. This
  130.    extension could be achieved either by tracking the evolution of the
  131.    OSI Standard or by work specific to the Internet. In practice, it is
  132.    likely to be a mixture of both.
  133.  
  134.    By deploying X.500 in some form on the Internet, a truly global and
  135.    universal Directory Service can be built that will provide Internet
  136.    users with fast access to all kinds of data. The X.500 Directory
  137.    Service in this case may range from a simple white pages service
  138.    (information on people and services) to coupling various existing
  139.    databases and information repositories in a universal way.
  140.  
  141.    Currently, several different but cooperating X.500 Directory Services
  142.    pilots are taking place on the Internet. These pilots form an
  143.    important base for experimenting with this new service. Starting with
  144.    these pilots, with the X.500 products arriving on the market today,
  145.    and given sufficient funding for the central services described in
  146.    this paper an operational X.500 Directory Service can be deployed.
  147.  
  148.    The final goal of the strategy described in this paper is to deploy a
  149.    fully operational Directory Service on the Internet, providing the
  150.    functions mentioned in the previous section.
  151.  
  152. 3.  INFORMATION FRAMEWORK
  153.  
  154.    The most critical aspect of the Directory Service is to establish an
  155.    Internet Information Framework. When establishing a sophisticated
  156.    distributed directory with a coherent information framework, it
  157.    involves substantial effort to map data onto this framework. This
  158.    effort is an operational effort and far outweighs the technical
  159.    effort of establishing servers and user agents.
  160.  
  161. 3.1   The Technical Model
  162.  
  163.    By choosing the X.500 model as a basis for the information framework,
  164.    it will also be part of a (future) global information framework. The
  165.    key aspects of this model are:
  166.  
  167.  
  168.  
  169.  
  170. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 3]
  171.  
  172. RFC 1430                     X.500 Strategy                February 1993
  173.  
  174.  
  175.    - A hierarchical navigational system that couples distributed
  176.      databases (of various kinds), which allows for management of the
  177.      data by the organization/person responsible for the data;
  178.  
  179.    - Each object in this information structure (called the Directory
  180.      Information Tree, DIT) is represented as an entry;
  181.  
  182.    - Objects are typed by an "object class", which permits multiple
  183.      inheritance;
  184.  
  185.    - An object is described by a set of attributes;
  186.  
  187.    - Each attribute is typed. Attribute types are hierarchical;
  188.  
  189.    - Each attribute type has an associated attribute syntax, which may
  190.      be generic or shared with other attributes (e.g., Integer Syntax;
  191.      Distinguished name Syntax); This allows for representation of
  192.      simple attributes (e.g., strings or bitmaps) or complex ones with
  193.      detailed structures.
  194.  
  195.    - Each entry has an unambiguous and unique global name;
  196.  
  197.    - Alternate hierarchies may be built by use of aliases or pointers of
  198.      distinguished name syntax.
  199.  
  200.    This framework allows for representation of basic objects such as
  201.    users within organizations. It is also highly extensible, and so can
  202.    be used for a range of other applications.
  203.  
  204. 3.2   Extending the Technical Model
  205.  
  206.    In the longer term, the model could be extended to deal with a number
  207.    of other requirements which potentially must be met by an Internet
  208.    Directory Service. Possible extensions include:
  209.  
  210.    - Support of ordered attributes (needed by some applications such as
  211.      message storage);
  212.  
  213.    - Extensions to allow unification with management information,
  214.      associated with SNMP (Simple Network Management Protocol) [CFSD90]
  215.      or other management protocols;
  216.  
  217.    - Handling of non-hierarchical data in a better manner for searching
  218.      and retrieval, whilst retaining the basic hierarchy for management
  219.      purposes.  This is essentially building a general purpose resource
  220.      location service on top of the basic infrastructure. It will need
  221.      work on the information model, and not just the access protocols.
  222.  
  223.  
  224.  
  225.  
  226. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 4]
  227.  
  228. RFC 1430                     X.500 Strategy                February 1993
  229.  
  230.  
  231.    It is noted that although X.500 may not provide the ultimate solution
  232.    to information retrieval, it has good potential for solving a lot of
  233.    information service related problems.
  234.  
  235. 3.3   The Operational Model
  236.  
  237.    To make the Directory Service with a coherent information framework
  238.    really operational requires a lot of effort. The most probable
  239.    operational model is one where larger organizations on the Internet
  240.    maintain their part of the DIT on their own DSA (Directory System
  241.    Agent). Smaller organizations will "rent" DSA space from regional
  242.    networks or other service providers. Together these DSAs will form
  243.    the Internet Directory Service Infrastructure. To couple the various
  244.    parts of the DIT that are contained on these Internet DSAs, a special
  245.    DSA containing the Root for the naming hierarchy within the DIT has
  246.    to be established and maintained.
  247.  
  248.    The following tasks can be foreseen:
  249.  
  250.    -  Defining the naming hierarchy; See section 4.
  251.    -  Creating the Directory Infrastructure; See section 5.
  252.    -  Getting the Data into the directory; and
  253.    -  Managing the data in the Directory. See section 6.
  254.  
  255. 4.  NAME ASSIGNMENT
  256.  
  257.    In order to deploy the Internet Directory Service, it is important to
  258.    define how the naming hierarchy will be structured. Although the
  259.    basic model suggests a simple monolithic "database" containing all of
  260.    the Internet's information infrastructure, with a namespace divided
  261.    along geographic boundaries, this may not be the definite model that
  262.    turns out to be the most appropriate to the Internet. Different
  263.    models may evolve according to the needs of the Internet and the
  264.    applications used on the Internet (i.e., some parts of the DIT may be
  265.    assigned at the root for the Internet). Below this one can envisage
  266.    several loosely coupled namespaces each with their own area of
  267.    applicability. This should be handled as a part of the general
  268.    operation of a directory service. An example of this might be
  269.    assignment of a representation of the Domain Namespace under the root
  270.    of the DIT. This is further discussed in [BHK91a].
  271.  
  272.    However, the core DIT information will be nationally assigned. The
  273.    parts of the DIT below country level will be managed differently in
  274.    each country. In many countries, registration authorities will be
  275.    established according to the OSI Standard [ISO]. This has been done
  276.    in some countries by the national ISO member body representative (for
  277.    example in the UK by BSI).
  278.  
  279.  
  280.  
  281.  
  282. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 5]
  283.  
  284. RFC 1430                     X.500 Strategy                February 1993
  285.  
  286.  
  287.    The lower parts of the hierarchy will, in general, be delegated to
  288.    organizations who will have control over Name Assignment in that part
  289.    of the tree. There is no reason to mandate how to assign this
  290.    hierarchy, although it is appropriate to give guidelines. Proposed
  291.    solutions to assignment of namespace are given in [BHK92].
  292.  
  293.    In North America, there is an alternative approach being developed by
  294.    the North American Directory Forum (NADF), which leverages existing
  295.    registration mechanisms [For91]. It is not yet clear what form a
  296.    final North American Directory Service will take. It is expected that
  297.    similar initiatives will be taken in other places, such as Europe.
  298.    For the Internet, the Internet Society (ISOC) has been suggested as a
  299.    possible Naming Authority.
  300.  
  301.    A discussion of the main issues involved with representing the Real
  302.    World in the Directory Service is part of the work undertaken by the
  303.    IETF OSI DS Working Group.
  304.  
  305.    The core of the Internet Directory will therefore come to exist of a
  306.    country based structure with different national naming schemes below
  307.    the countries.  It is clearly desirable that the Internet Directory
  308.    Service follows any evolving national and international hierarchies.
  309.    However, this should not be allowed to cause undue delay. The
  310.    strategy proposed is to proceed with name assignment as needed, and
  311.    to establish interim registration authorities where necessary, taking
  312.    practical steps to be aligned with emerging national authorities
  313.    wherever possible.
  314.  
  315.    It is suggested that the Internet Directory Service does two things:
  316.  
  317.    First, each national part of the Internet DIT namespace should be
  318.    delegated to an appropriate organization, which will usually be in
  319.    the country of question.  Second, the delegated organization should
  320.    assign names for that country as part of the Internet Directory
  321.    Service. This should be done in a manner which is appropriately
  322.    aligned with any emerging local or national service, but does not
  323.    unduly delay the deployment of the Internet Directory Service.  For
  324.    most countries, this will fit in as a natural evolution of the early
  325.    directory piloting, where operators of pilots have acted as interim
  326.    name registration authorities.
  327.  
  328. 5.  DIRECTORY INFRASTRUCTURE
  329.  
  330.    To provide access to the Internet Directory Service, an
  331.    infrastructure has to be built. Although the technical components of
  332.    an X.500 infrastructure are clear: DSAs (that hold the actual data)
  333.    and DUAs (that allow users and applications to access the data), a
  334.    lot more is needed for deployment of an Internet Directory Service.
  335.  
  336.  
  337.  
  338. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 6]
  339.  
  340. RFC 1430                     X.500 Strategy                February 1993
  341.  
  342.  
  343.    The Integrated Directory Services (IDS) Working Group of the IETF is
  344.    playing a key role in solving most of the issues that are related to
  345.    the building of an appropriate infrastructure.
  346.  
  347.    Many of the issues cited in this section have come forward out of
  348.    interim pilots that have been established on the Internet:
  349.  
  350.    PSI White Pages Pilot
  351.       This is a pilot service which is operating X.500 on the Internet.
  352.       In many ways it is operating as an Internet wide pilot.
  353.  
  354.    FOX
  355.       Fielding Operational X.500, a project to explore the development
  356.       and interoperability of X.500 implementations.
  357.  
  358.    Paradise (Piloting A ReseArch DIrectory Service in Europe)
  359.       This project has been providing the necessary glue to hold the
  360.       various national activities together [Par91].
  361.  
  362. 5.1   Short Term Requirements
  363.  
  364.    -  Central Operations. There is a need for a number of operations
  365.       to be managed as a service for the whole Internet. These services
  366.       are:
  367.  
  368.       o A root DSA; containing the top-level of the DIT, has to be
  369.         provided.  Currently, this root DSA is managed by the Paradise
  370.         project.
  371.  
  372.       o Name assignment; Inserting names into the Directory, this has
  373.         been discussed in section 4. This could be done in conjunction
  374.         with the appropriate Registration Authority or by the
  375.         Registration Authority.  In most cases it is likely to be the
  376.         former, and mechanisms will need to be set up to allow
  377.         organizations to get their names installed into the directory,
  378.         either direct or through the registration authority.
  379.  
  380.       o Knowledge management; i.e., the information on "which DSA holds
  381.         what part of the DIT, and how can that DSA be accessed". DSAs
  382.         will be established by Organizations. There will be a need to
  383.         centrally coordinate the management of the knowledge information
  384.         associated with these DSAs. This is likely to be coupled to the
  385.         name assignment.
  386.  
  387.       o Knowledge and Data replication; For the Directory to perform
  388.         well, knowledge and data high up in the DIT must be
  389.         significantly replicated. A service must be provided to make
  390.         replicated information available to DSAs that need it.
  391.  
  392.  
  393.  
  394. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 7]
  395.  
  396. RFC 1430                     X.500 Strategy                February 1993
  397.  
  398.  
  399.       It is suggested that for the time being, Paradise should be used
  400.       as the initial basis for handling the top-level of the DIT and for
  401.       provision of the central services. However, the services mentioned
  402.       above need to be provided at a national level for every
  403.       participating country in the Internet Directory Service. Whenever
  404.       an organization starts a new country branch of the DIT in the
  405.       Internet Directory Service the central operations will have to
  406.       help out to make sure that these services will be properly
  407.       installed on a national level.
  408.  
  409.    - An effective service will need to have sufficient implementations,
  410.      in order to give full coverage over different hardware and software
  411.      platforms, and to demonstrate openness. The recent Directory
  412.      Information Services (pilot) Infrastructure Working Group's (DISI)
  413.      Survey of Directory Implementations suggests that there will not be
  414.      a problem here.  This provides a list of available X.500
  415.      implementations and their capabilities [LW91].
  416.  
  417.    - An executive summary, necessary to convince the management of
  418.      computer centers to invest manpower into setting up a X.500
  419.      Directory Service.  This is provided by DISI [WR92].
  420.  
  421.    - Due to the possible different and rather independent structured
  422.      namespaces that can be envisaged in the DIT for different purposes,
  423.      DUAs will have to be "tuned intelligently" for the applications that
  424.      they are used for.
  425.  
  426.    - To allow users easy access to the Internet Directory Service even
  427.      from low powered workstations, a lightweight protocol has to be
  428.      developed over TCP/IP. Already two private protocols that do this
  429.      have been developed: The Michigan DIXIE protocol [HSB91] and the PSI
  430.      Directory Assistance Service [Ros91]. The IETF OSI Directory
  431.      Services Working Group (OSI-DS WG) is currently working on a
  432.      standard lightweight protocol called LDAP.
  433.  
  434.    - Although the Internet Directory Service does not have to make any
  435.      mandatory requirements about the use of lower layers, it is noted
  436.      that the use of STD 35, RFC 1006 to allow use of OSI applications on
  437.      top of TCP/IP is essential for deployment in the Internet. Other
  438.      stacks like the ones using CLNS, CONS and X.25(80) will probably
  439.      also be deployed in parts of the Internet. DSAs with different
  440.      stacks will be linked through use of either application level relays
  441.      (chaining) or Transport Service bridges.
  442.  
  443.    - There are multiple issues that are not dealt with (properly) in the
  444.      X.500 standard and thus prevent the building of an Internet
  445.      Directory service.  Intermediate solutions for these issues have to
  446.      be established in an "open" way. The results will have to be
  447.  
  448.  
  449.  
  450. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 8]
  451.  
  452. RFC 1430                     X.500 Strategy                February 1993
  453.  
  454.  
  455.      deployed as well as to be fed back into the relevant standard
  456.      committees. The IETF OSI-DS WG deals with these issues. Section 7
  457.      describes several of these issues.
  458.  
  459.    - Site support. The IETF IDS WG is looking at providing the necessary
  460.      documentation to help with the provision of support for Directory
  461.      users at participating sites.
  462.  
  463. 5.2   Medium Term Requirements
  464.  
  465.    - Enhanced performance is necessary to allow for a real global usage;
  466.  
  467.    - The schema has to be extended to allow for various kinds of data,
  468.      e.g.,:
  469.  
  470.       o  NIC data;
  471.       o  Resource location;
  472.  
  473.    - Support for Internet Message Handling services (RFC-822, MIME and
  474.      X.400).  This work is already undertaken by the IETF MHS-DS WG.
  475.  
  476. 5.3   Long Term Requirements
  477.  
  478.    - To make sure that X.500 evolves into an operational service, it is
  479.      essential to track its evolution, and to feed back into the
  480.      evolution process.
  481.  
  482.    - Interface existing RDBMS into the Directory Service.
  483.  
  484.    - To increase the performance of the directory, and thereby making it
  485.      useful for an even wider range of applications (e.g., policy based
  486.      routing), a lightweight protocol for access and system usage is
  487.      needed.
  488.  
  489. 6.  DATAMANAGEMENT
  490.  
  491.    The whole of the Directory Infrastructure won't stand much chance
  492.    without proper datamanagement of the data contained within the DIT.
  493.    Procedures need to be established to assure a certain Level of
  494.    Quality of the data contained in the DIT.
  495.  
  496.    Due to the very nature of X.500, the management of the data is
  497.    distributed over various sources. This has the obvious advantage that
  498.    the data will be maintained by the owner of the data. It does
  499.    however, make it quite impossible to describe one single procedure
  500.    for datamanagement.
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                    [Page 9]
  507.  
  508. RFC 1430                     X.500 Strategy                February 1993
  509.  
  510.  
  511.    For the Internet Directory Service, guidelines will have to be
  512.    developed (by the IETF IDS WG), to help organizations that start with
  513.    deployment of X.500 on how to manage data in their part of the DIT.
  514.    The guidelines should describe a minimum level of quality that has to
  515.    be supplied to make the service operational. The IETF OSI-DS WG will
  516.    initiate a pilot on Quality of Service parameters in the Directory,
  517.    that will be of use.
  518.  
  519.    Pilot datamanagement projects will have to be done (e.g., existing
  520.    databases should be connected to the Internet Directory Service).
  521.    Tools that are developed to achieve this should be made available to
  522.    the Internet community for possible future use.
  523.  
  524. 6.1   Legal Issues
  525.  
  526.    Most countries connected to the Internet have some sort of law that
  527.    dictates how data on people can and cannot be made available. These
  528.    laws deal with privacy and registration issues, and will differ from
  529.    country to country.  It is suggested that each of the national
  530.    organizations within the Internet that manages the Internet Directory
  531.    Services master for that country, undertake some research as to the
  532.    applicability of laws within that country on data made public through
  533.    use of X.500.
  534.  
  535.    In the mean time, a general "User Bill of Rights" should be
  536.    established to indicate what the proper use of the Internet Directory
  537.    Service is. This "Bill of Rights" could be drafted by the IETF IDS
  538.    WG.  As a basis, the NADF "User Bill of Rights" [For92] can be used.
  539.  
  540. 7.  TECHNICAL ISSUES
  541.  
  542.    The IETF has established the OSI-DS WG. The major component of the
  543.    initial work of this group is to establish a technical framework for
  544.    deploying a Directory Service on the Internet, making use of the
  545.    X.500 protocols and services [CCI88b].  This section describes the
  546.    work already done by this working group, which has been implicitly
  547.    focused on the technical infrastructure needed to deploy the Internet
  548.    Directory service.
  549.  
  550.    The OSI Directory Standards do not yet contain sufficient specifics
  551.    to enable the Internet Directory Service to be built. Full openness
  552.    and interoperability are a key goal, so we may need Internet specific
  553.    agreements, at least until the ISO standards are more complete. This
  554.    section notes areas where the standards do not have sufficient
  555.    coverage, and indicates the RFCs which have been written to overcome
  556.    these problems.
  557.  
  558.    The work is being limited to (reasonably well) understood issues.
  559.  
  560.  
  561.  
  562. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 10]
  563.  
  564. RFC 1430                     X.500 Strategy                February 1993
  565.  
  566.  
  567.    This means that whilst we will attempt to solve a wider range of
  568.    problems, not all potential requirements will necessarily be met.
  569.  
  570.    The technical work is done in conjunction with the RARE WG on Network
  571.    Application Support WG (formerly RARE WG3). The IETF WGs and the RARE
  572.    WG have a common technical mailing list. It is intended that this
  573.    will lead to a common European and North American technical approach.
  574.  
  575. 7.1   Schema
  576.  
  577.    A Directory needs to be used in the context of an Information
  578.    Framework. The standard directory provides a number of a attributes
  579.    and object classes to enable basic operation. It is certain that the
  580.    Internet community will have requirements for additional attributes
  581.    and object classes. There is a need to establish a mechanism to
  582.    register such information.
  583.  
  584.    Pilots in the European RARE Community and the US PSI White Pages
  585.    Pilot have based their information framework on the THORN and RARE
  586.    Naming Architecture. This architecture should be used for the
  587.    Internet Directory Service, in conjunction with COSINE based services
  588.    in Europe. A revised version of the Naming Architecture, with a
  589.    mechanism for registration of new attributes and object classes, has
  590.    been released as RFC 1274 [BHK91a].
  591.  
  592. 7.2   Use on the Internet
  593.  
  594.    It is a recognized policy on the Internet to deploy OSI Applications
  595.    over non-OSI lower layers (such as STD 35, RFC 1006) [RC87]. This
  596.    policy allows deployment of OSI Applications before an OSI lower
  597.    layer infrastructure has been deployed. Thus, the Internet Directory
  598.    Service will decouple deployment of the OSI Directory from deployment
  599.    of the OSI lower layers. As the Internet Directory service will
  600.    extend into the far corners of the Internet namespace, where the
  601.    underlying technology is not always TCP/IP, the Internet Directory
  602.    Service will not make any mandatory requirements about use of lower
  603.    layers. When configuring the Internet Directory Services, variations
  604.    in the lower layers must be considered. The following options are
  605.    possible:
  606.  
  607.    - Operation on top of TCP/IP using a lightweight protocol.
  608.  
  609.    - Operation over TCP/IP using STD 35, RFC 1006. This is a practical
  610.      requirement of deployment at very many Internet sites, and is the
  611.      basis of the existing services. It is highly recommended that all
  612.      participating DSAs support this stack.
  613.  
  614.    - Use of OSI Network Service (Connection Oriented or Connectionless).
  615.  
  616.  
  617.  
  618. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 11]
  619.  
  620. RFC 1430                     X.500 Strategy                February 1993
  621.  
  622.  
  623.    - X.25(80) will probably not be used in the core infrastructure of
  624.      the Internet Directory Service, but is the basis of some European
  625.      activities.  It may be needed later to interconnect with US
  626.      commercial systems not on the Internet. There will be a practical
  627.      need to interwork with DSAs which only support this stack.
  628.  
  629.    This approach has the following implications:
  630.  
  631.    1. There is a need to represent TCP/IP addresses within OSI Network
  632.       Addresses. This is specified in RFC 1277 [HK91a].
  633.  
  634.    2. It will be desirable to have a uniform method to present Network
  635.       Addresses of this style. Therefore, a string representation of
  636.       presentation addresses is specified in RFC 1278 [HK91d].
  637.  
  638.    3. This approach leads to the situation where not all DSAs can
  639.       communicate directly due the different choice of lower layers.
  640.       This is already a practical result of many European sites operating
  641.       DSAs over X.25.  When the Internet Directory Service is deployed,
  642.       the issue of which DSAs operate which stacks must be considered in
  643.       order to achieve a coherent service.  In particular, there may be a
  644.       need to require DSAs that serve parts higher up in the DIT to serve
  645.       multiple stacks. This will be tackled as an operational issue.
  646.  
  647.    4. There may be a requirement to extend the distributed operations, so
  648.       that there is no requirement for full connectivity (i.e., each DSA
  649.       supports each stack). A solution to this problem, by defining
  650.       "relay DSAs" is specified in RFC 1276 [HK91b].
  651.  
  652. 7.3   Replication of Knowledge and Data
  653.  
  654.    There are a number of requirements on replication, both of data (the
  655.    actual information on objects in the directory) and knowledge (the
  656.    information on where do I find what data) information, which must be
  657.    met before an Internet Directory can be deployed. The 1988 standard
  658.    cannot be used as is, because it does not deal with replication or
  659.    caching. This leads to serious problems with performance. There is a
  660.    partial solution available in the 1992 version of the standard,
  661.    however there are no products available yet that implement this
  662.    solution.  These issues are discussed in more detail in RFC 1275
  663.    [HK91c].
  664.  
  665.    As it took too long for 1992 implementations to arrive to be of any
  666.    help to the already rapidly growing pilot that urgently needed a
  667.    solution, an option was chosen to use a simple interim approach as
  668.    defined in RFC 1276.  It will be clearly emphasized that this is an
  669.    interim approach, which will be phased out as soon as the appropriate
  670.    standards are available and stable implementations are deployed. The
  671.  
  672.  
  673.  
  674. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 12]
  675.  
  676. RFC 1430                     X.500 Strategy                February 1993
  677.  
  678.  
  679.    interim approach is based on the approach used in the QUIPU
  680.    Implementation and it is widely deployed in the existing pilots.
  681.  
  682. 7.4   Presentation of Directory Names
  683.  
  684.    The standard does not specify a means to present directory names to
  685.    the user. This is seen as a serious deficiency, and a standard for
  686.    presenting directory names is required. For Distinguished Names, a
  687.    string representation is defined in [HK92a]. However, as the
  688.    distinguished name is not very friendly for the user, a more user
  689.    oriented specification of a standard format for representing names,
  690.    and procedures to resolve them is chosen on the Internet, and is
  691.    specified in [HK92b].
  692.  
  693. 7.5   DSA Naming and MD Structure
  694.  
  695.    There are some critical issues related to naming of DSAs and the
  696.    structure of Directory Management Domains. The main issues are:
  697.  
  698.    - It is hard to achieve very high replication of knowledge
  699.      information as this is very widely spread;
  700.  
  701.    - There is a need to give DSAs more reasonable names, which will
  702.      contain an indication on the role of the DSA; This is necessary for
  703.      DSAs high up the DIT.
  704.  
  705.    - There is too much DIT clutter in the current pilots;
  706.  
  707.    - There is no real concept of a DMD (Directory Management Domain)
  708.      authority.
  709.  
  710.    These will be significant as the directory increases in size by
  711.    orders of magnitude. The IETF OSI-DS WG is working to develop a
  712.    solution in this area.
  713.  
  714. 8. SECURITY
  715.  
  716.    A Directory can be an important component in the overall provision of
  717.    security in a distributed system environment, especially when
  718.    public-key cryptographic technology is employed. The directory can
  719.    serve as a repository for authentication information, which, in turn,
  720.    forms the basis of a number of OSI Authentication Services (e.g.,
  721.    X.400) and non-OSI Services (e.g., privacy-enhanced mail, PEM). The
  722.    directory may also use this and other stored authentication
  723.    information to provide a wide range of security Services used by the
  724.    Directory system itself.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 13]
  731.  
  732. RFC 1430                     X.500 Strategy                February 1993
  733.  
  734.  
  735. 8.1   Directory Provision of Authentication
  736.  
  737.    The directory will be used to provide X.509 strong authentication.
  738.    This places minimal requirements on the directory. To use this
  739.    infrastructure, users of authentication services must have access to
  740.    the directory. In practice, this type of authentication can be
  741.    deployed only on a limited scale without use of a directory, and so
  742.    this provision is critical for applications such as Privacy Enhanced
  743.    Mail [Lin93]. The PEM development is considering issues relating to
  744.    deploying Certification Authorities, and this discussion is not
  745.    duplicated here.
  746.  
  747.    PEM defines a key management architecture based on the use of
  748.    public-key certificates, in support of the message encipherment and
  749.    authentication procedures defined in [Lin93]. The PEM certificate
  750.    management design [Ken93] makes use of the authentication framework
  751.    defined by X.509. In this framework, as adopted by PEM, a
  752.    "certification authority" representing an organization applies a
  753.    digital signature to a collection of data consisting of a user's
  754.    public component, various information that serves to identify the
  755.    user, and the identity of the organization whose signature is
  756.    affixed.  This establishes a binding between these user credentials,
  757.    the user's public component and the organization which vouches for
  758.    this binding. The resulting, signed, data item is called a
  759.    certificate. The organization identified as the certifying authority
  760.    for the certificate is the "issuer" of that certificate. The format
  761.    of the certificate is defined in X.509.
  762.  
  763.    In signing the certificate, the certification authority vouches for
  764.    the user's identification, in the context specified by the identity
  765.    of the issuer. Various types of organization may issue certificates,
  766.    including corporate, educational, professional, or governmental
  767.    entities. Moreover, these issuers may operate under different
  768.    certification policies, so that not all certificates may be equally
  769.    credible (i.e., some certificates may be more trustworthy as accurate
  770.    identifiers of users, organizations, mailing lists, etc). The PEM
  771.    certificate management design allows for this diversity of
  772.    certification policies, while ensuring that any certificate can be
  773.    traced unambiguously to the policy under which it was issued.
  774.  
  775.    The digital signature is affixed on behalf of that organization and
  776.    is in a form which can be recognized by all members of the privacy-
  777.    enhanced electronic mail community. This ability to universally
  778.    verify any PEM certificate results because the PEM certification
  779.    design is a singly rooted tree, in which the Internet Society acts as
  780.    the root. Once generated, certificates can be stored in directory
  781.    servers, transmitted via unsecure message exchanges, or distributed
  782.    via any other means that make certificates easily accessible to
  783.  
  784.  
  785.  
  786. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 14]
  787.  
  788. RFC 1430                     X.500 Strategy                February 1993
  789.  
  790.  
  791.    message originators, without regard for the security of the
  792.    transmission medium.
  793.  
  794. 8.2   Directory Security
  795.  
  796.    A number of security services are possible with the directory:
  797.  
  798.    Peer Authentication at Bind
  799.       Authentication (one or two way) between DUA/DSA and DSA/DSA,
  800.       established during the bind operation. This authentication may be
  801.       provided using simple passwords (not recommended), one-way hashed
  802.       passwords (more secure), or via public key cryptography (most
  803.       secure). The various authentication options are specified in
  804.       X.500(88), but most existent implementations implement only simple
  805.       password authentication.
  806.  
  807.    Per-operation Authentication and Integrity
  808.       This is usually used to identify the DUA originating an operation
  809.       to the Directory (e.g., to authenticate prior to data
  810.       modification). It may also be used to verify the identity of the
  811.       DSA which provided data in a response to the user. In both
  812.       examples, the integrity of the data also is ensured through the
  813.       use of digital signatures. This is specified in X.500(88), but not
  814.       yet widely implemented.
  815.  
  816.    Single Entry Access Control
  817.       This is used to control which users (DUAs) can access and modify
  818.       data within an entry. This is specified in X.500(92) and most DSA
  819.       implementations provide this function.
  820.  
  821.    Multiple Entry Access Control
  822.       This is used to control search and list operations, in order to
  823.       allow location of information by searching, but to deter
  824.       "trawling" of information and organizational structure. Usually,
  825.       these access controls are limited in their ability to prevent
  826.       trawling because of the conflicting goal of allowing a certain
  827.       level of legitimate browsing in support of "white pages"
  828.       functionality.
  829.  
  830.    Service Authorization
  831.       This allows DSAs to control service in a data independent manner,
  832.       based on peer authentication. For example, one might prevent
  833.       students from making non-local queries, while permitting such
  834.       queries by faculty and staff.
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 15]
  843.  
  844. RFC 1430                     X.500 Strategy                February 1993
  845.  
  846.  
  847.    Security Policy
  848.       This term encompasses the security goals for which data access
  849.       control, service authorization, and authentication mechanisms are
  850.       used to implement. For example, a local security policy might
  851.       require that all directory database modifications employ strong
  852.       authentication and originate from a computer at a known (local)
  853.       location.
  854.  
  855.    Data Confidentiality
  856.       The directory does not include explicit features to protect the
  857.       confidentiality of data while in transit (e.g., between a DUA and
  858.       DSA or between DSAs). Instead, it is assured that lower layer
  859.       security protocols or other local security facilities will be
  860.       employed to provide this security service. Ongoing work on
  861.       adaptation of the Network Layer Security Protocol (NLSP) is a
  862.       candidate for provision of this security service with directories.
  863.  
  864.    There is no specification of any Internet-wide security policy for
  865.    directories, nor are there currently any security mechanisms required
  866.    of all directories. Deployment of a directory could be based on a
  867.    variety of policies:
  868.  
  869.    - Read only system, containing only public data and restricted to
  870.      local modification.
  871.  
  872.    - Use of X.509 authentication, and private access control mechanisms
  873.      (this will not allow open access control management, but this is not
  874.      seen as a fundamental problem).
  875.  
  876.    It will be important to understand if global Internet requirements
  877.    for minimum essential directory security mechanisms will be required
  878.    to promote widespread use of directories. We recommend that an
  879.    informational RFC be written to analyze this issue, with an
  880.    operational policy guidelines or applicability statement RFC to
  881.    follow.
  882.  
  883. 9. RELATION TO DNS
  884.  
  885.    It is important to establish the relationship between the proposed
  886.    Internet Directory, and the existing Domain Name System. An
  887.    Experimental Protocol RFC (RFC 1279) proposes a mapping of DNS
  888.    information onto the Directory. Experiments should be conducted in
  889.    this area [HK91e].
  890.  
  891. 10. EXTERNAL CONNECTIONS
  892.  
  893.    It will be important for this activity to maintain suitable external
  894.    liaisons. In particular to:
  895.  
  896.  
  897.  
  898. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 16]
  899.  
  900. RFC 1430                     X.500 Strategy                February 1993
  901.  
  902.  
  903.    Other Directory Services and Directory Pilots
  904.  
  905.       To ensure a service which is coherent with other groups building
  906.       X.500 services. e.g.,:
  907.  
  908.       -  Paradise
  909.       -  NADF
  910.       -  FOX
  911.       -  PSI White Pages
  912.  
  913.    Standards Bodies
  914.  
  915.       To feed back experience gained from this activity, so that the
  916.       next round of standards meets as many of the Internet requirements
  917.       as possible. e.g.,:
  918.  
  919.       -  CCITT/ISO
  920.       -  RARE WG-NAS
  921.       -  EWOS/OIW
  922.       -  ETSI
  923.  
  924. 11. REFERENCES
  925.  
  926.  
  927.    [BHK91a]  Barker, P., and S. Hardcastle-Kille, "The COSINE and
  928.              Internet X.500 Schema", RFC 1274, Department of Computer
  929.              Science, University College London, November 1991.
  930.  
  931.    [BHK92]   Barker, P., and S. Hardcastle-Kille, "Naming Guidelines for
  932.              Directory Pilots", RFC 1384, Department of Computer Science,
  933.              University College London, ISODE Consortium, January 1993.
  934.  
  935.    [CCI88a]  The Directory --- authentication framework, December 1988.
  936.              CCITT Recommendation X.509.
  937.  
  938.    [CCI88b]  The Directory --- overview of concepts, models and services,
  939.              December 1988. CCITT X.500 Series Recommendations.
  940.  
  941.    [CCI90]   The Directory --- part 9 --- replication, October 1990.
  942.              ISO/IEC CD 9594-9 Ottawa output.
  943.  
  944.    [CFSD90]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
  945.              Simple Network Management Protocol", STD 15, RFC 1157,
  946.              SNMP Research, Performance Systems International, MIT
  947.              Laboratory for Computer Science, May 1990.
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 17]
  955.  
  956. RFC 1430                     X.500 Strategy                February 1993
  957.  
  958.  
  959.    [For91]   The North American Directory Forum, "A Naming Scheme
  960.              for C=US", RFC 1255, NADF, September 1991.
  961.              Also NADF-175.  (See also RFC 1417.)
  962.  
  963.    [For92]   The North American directory Forum, "User Bill of Rights
  964.              for Entries and Listing in the Public Directory", RFC 1295,
  965.              NADF, January 1992.  (See also RFC 1417.)
  966.  
  967.    [HK91a]   Hardcastle-Kille, S., "Encoding network addresses to
  968.              support operation over non-OSI lower layers", RFC 1277,
  969.              Department of Computer Science, University College London,
  970.              November 1991.
  971.  
  972.    [HK91b]   Hardcastle-Kille, S., "Replication and distributed
  973.              operations extensions to provide an internet directory
  974.              using X.500", RFC 1276, Department of Computer Science,
  975.              University College London, November 1991.
  976.  
  977.    [HK91c]   Hardcastle-Kille, S., "Replication requirement to
  978.              provide an internet directory using X.500", RFC 1275,
  979.              Department of Computer Science, University College
  980.              London, November 1991.
  981.  
  982.    [HK91d]   Hardcastle-Kille, S., "A string encoding of presentation
  983.              address", RFC 1278, Department of Computer Science,
  984.              University College London, November 1991.
  985.  
  986.    [HK91e]   Hardcastle-Kille, S., "X.500 and domains", RFC 1279,
  987.              Department of Computer Science, University College
  988.              London, November 1991.
  989.  
  990.    [HK92a]   Hardcastle-Kille, S., "A string representation of
  991.              Distinguished Names", Department of Computer Science,
  992.              University College London, Work in Progress.
  993.  
  994.    [HK92b]   Hardcastle-Kille, S., "Using the OSI directory to achieve
  995.              user friendly naming", Department of Computer Science,
  996.              University College London, Work in Progress.
  997.  
  998.    [HSB91]   Howes, R., Smith, M., and B. Beecher, "DIXIE Protocol
  999.              Specification", RFC 1249, University of Michigan,
  1000.              July 1991.
  1001.  
  1002.    [ISO]     Procedures for the operation of OSI registration
  1003.              authorities --- part 1: general procedures. ISO/IEC 9834-1.
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 18]
  1011.  
  1012. RFC 1430                     X.500 Strategy                February 1993
  1013.  
  1014.  
  1015.    [Ken93]   Kent, S., "Privacy Enhancement for Internet Electronic
  1016.              Mail: Part II - Certificate-based Key Management, RFC 1422,
  1017.              BBN, February 1993.
  1018.  
  1019.    [Kil88]   Kille, S., "The QUIPU Directory Service", In IFIP WG 6.5
  1020.              Conference on Message Handling Systems and Distributed
  1021.              Applications, pages 173--186. North Holland Publishing,
  1022.              October 1988.
  1023.  
  1024.    [Kil89]   Kille, S., "The THORN and RARE Naming Architecture",
  1025.              Technical report, Department of Computer Science,
  1026.              University College London, June 1989. THORN Report UCL-64
  1027.              (version 2).
  1028.  
  1029.    [Lin93]   Linn, J., "Privacy Enhancement for Internet Electronic
  1030.              Mail: Part I - Message Encryption and Authentication
  1031.              Procedures", RFC 1421, February 1993.
  1032.  
  1033.    [LW91]    Lang, R., and R. Wright, "A Catalog of Available X.500
  1034.              Implementations", FYI 11, RFC 1292, SRI International,
  1035.              Lawrence Berkeley Laboratory, January 1992.
  1036.  
  1037.    [Lyn91]   Lynch, C., "The Z39.50 information retrieval protocol: An
  1038.              overview and status report", Computer Communication Review,
  1039.              21(1):58--70, January 1991.
  1040.  
  1041.    [Par91]   Paradise International Report, Cosine. Paradise project,
  1042.              Department of Computer Science, University College London.
  1043.              November 1991.
  1044.  
  1045.    [RC87]    Rose, M., and D. Cass, "ISO Transport Services on
  1046.              top of the TCP", STD 35, RFC 1006, Northrop Corporation
  1047.              Technology Center, May 1987.
  1048.  
  1049.    [Ros91]   Rose, M., "Directory Assistance Service", RFC 1202,
  1050.              Performance Systems International, February 1991.
  1051.  
  1052.    [WR92]    Weider, C., and J. Reynolds, "Executive Introduction to
  1053.              Directory Services Using the X.500 Protocol", FYI 13,
  1054.              RFC 1308, ANS, ISI, March 1992.
  1055.  
  1056. 12.  Security Considerations
  1057.  
  1058.    Security issues are discussed in Section 8.
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 19]
  1067.  
  1068. RFC 1430                     X.500 Strategy                February 1993
  1069.  
  1070.  
  1071. 13. Authors' Addresses
  1072.  
  1073.    Steve Hardcastle-Kille
  1074.    ISODE Consortium
  1075.    PO box 505
  1076.    SW11 1DX London
  1077.    England
  1078.    Phone: +44-71-223-4062
  1079.    EMail: S.Kille@isode.com
  1080.  
  1081.  
  1082.    Erik Huizer
  1083.    SURFnet bv
  1084.    PO box 19035
  1085.    3501 DA Utrecht
  1086.    The Netherlands
  1087.    Phone: +31-30 310290
  1088.    Email: Erik.Huizer@SURFnet.nl
  1089.  
  1090.  
  1091.    Vinton Cerf
  1092.    Corporation for National Research Initiatives
  1093.    1895 Preston White Drive, Suite 100
  1094.    Reston, VA 22091
  1095.    Phone: (703) 620-8990
  1096.    EMail: vcerf@cnri.reston.va.us
  1097.  
  1098.  
  1099.    Russ Hobby
  1100.    University of California, Davis
  1101.    Computing Services
  1102.    Surge II Room 1400
  1103.    Davis, CA 95616
  1104.    Phone: (916) 752-0236
  1105.    EMail: rdhobby@ucdavis.edu
  1106.  
  1107.  
  1108.    Steve Kent
  1109.    Bolt, Beranek, and Newman
  1110.    50 Moulton Street
  1111.    Cambridge, MA 02138
  1112.    Phone: (617) 873-3988
  1113.    EMail: skent@bbn.com
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Hardcastle-Kille, Huizer, Cerf, Hobby & Kent                   [Page 20]
  1123.